In computer or communications networks, different web sites or web applications may provide different services for the benefit of a user. For instance, one web site or web application may manage an email account of the user. Another web site or web application may enable the storage of photos for sharing them to members of a social network of the user. Yet another web site or web application may act as a bookshop managing a user's bookshop account. Yet a further web site or web application may offer to print images and photos and deliver them to users. The possibilities are endless.
Yet, web sites and web applications may want to offer new services “which tie together functionality from other sites” (Eran Hammer-Lahav, “Explaining OAuth”, Sep. 5, 2007, http://hueniverse.com/2007/09/explaining-oauth/—retrieved on Sep. 15, 2009, here referred to as ref. [1]). For instance, a digital photo lab printing web application (such as an exemplary web site “printer.consumer.com”) may want to retrieve, on behalf of a user, photos stored in a digital image hosting web site (such as an exemplary site “photos.container.com”) with which the user has an account, in order to print and deliver these photos to the user.
In order to implement a web service integrating protected resources from different web sites and web applications, a first web site or web application, here referred to as the “consumer”, may request the user to provide his or her credentials to access a second web site or web application, here referred to as the “service provider” (although the consumer also provides services). In the above-mentioned example, the consumer would be the digital photo lab printing web application, the service provider would be the digital image hosting web site, and the protected resources would be the user's private photos. In other words, the consumer may request the user to provide his or her username and password to access the service provider. This, however, exposes the user's password and enables the password to be used by someone else for any actions associated with the user's account within the service provider (such as “even change your password and lock you out”, ref. [1], section “What is it For”).
To solve that problem, the OAuth protocol has been developed (Atwood, M. et al, “OAuth Core 1.0 Revision A”, Jun. 24, 2009, http://oauth.net/core/1.0a—retrieved on Sep. 15, 2009, here referred to as ref. [2]). The OAuth protocol enables a web site or web application, i.e. the consumer, to access protected resources from another web site or web application, i.e. the service provider, without requiring the users to disclose their service provider credentials to the consumers (ref. [2], Abstract). The OAuth protocol may be viewed as an application programming interface (API) access delegation protocol. The valet key analogy, explained in ref. [1], section “What is it For”, may help to intuitively understand the purpose of the OAuth protocol.
In the OAuth protocol, the authentication, i.e. “the process in which users grant access to their protected resources without sharing their credentials with the consumer” (ref. [2], “6. Authenticating with OAuth”), works as follows.
The consumer obtains an unauthorized request token from the service provider. The consumer directs the user to the service provider via the user's web browser, using the service provider's user authorization URL (“URL” stands here for “Uniform Resource Locator”). The user then authenticates him- or herself with the service provider. In other words, the user signs into the service provider's web site. At no time the user provides his or her service provider credentials to the consumer.
The service provider then asks the user whether he or she agrees with the consumer being granted access to the protected resources. To do so, the service provider presents, to the user, information about the protected resources to which the consumer wants to access. The information includes the duration of requested access and the type of access (e.g. copy, modify, or delete a protected resource). The information may for instance be presented on a web page of the service provider web site with an exemplary message such as “The web site <consumer-name> is requesting access to your private photos for the next 1 hour. Do you approve such access?” The user then grants or denies permission for the service provider to give to the consumer the envisaged access on behalf of the user.
If the user agrees, the request token is authorized and the user is directed back to the consumer, so that the consumer is notified that the request token has been authorized. The authorized request token is then exchanged for an access token and the protected resources can be accessed by the consumer on behalf of the user. If the user denies permission, the consumer is notified that the request token has been revoked.
An example of authentication process using the OAuth protocol is presented in Eran Hammer-Lahav, “Beginner's Guide to OAuth—Part II: Protocol Workflow”, Oct. 15, 2007, http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/—retrieved on Sep. 15, 2009.
It is desirable to improve the methods, physical entities and computer programs to manage access, on behalf of users, by web sites or web applications, referred to here as consumers, to protected resources associated with the users on other web sites or web applications, referred to here as service providers, with in mind the need of reducing the operational burden on the users.